appDisplay: Reimplement drag motion using page indicators
This simplified the _handleDragOvershoot() callback quite a lot.
Instead of transforming point positions and checking them against
grid coordinates, merely check if the drop target is one of the
page indicators.
Make the next and previous page arrows be StButtons, with their
'icon-name' property matching the current StIcon icon name, and
use the 'clicked' signal to switch pages.
Remove the 'button-press' callback the scroll view, since the
buttons take over this functionality.
appDisplay: Readd next and previous page icons previews
This was lost 2 commits ago, but now we reimplement this in a
different way. There is some jesting with allocations, since
we cannot use transformed positions while changing translation
of the icons. This new implementation works regardless of the
screen resolution.
appDisplay: Use custom layout manager for page indicators
This is a major departure to how page previews used to work. Add
a new layout manager that handles showing and hiding page previews
and navigation arrows. Move most of the code handling page previews
to this new layout manager.
The layout manager allocates at most 20% of the screen width for
the previews, and at least the width of the arrow.
The next and previous page peeking effect is temporarily lost with
this commit, but will be reintroduced in later commits.
The API surface of IconGrid was originally meant to be only
setGridModes(), however findBestModeForSize() ended up being
called by AppDisplay code. Now that FolderGrid sets the modes
correctly, we don't need to skip calling findBestModeForSize()
anymore.
Always call findBestModeForSize() during IconGrid's allocation.
Add an underscore to findBestModeForSize() since it's now back
to be a private method of IconGrid.
Back in the day, adaptToSize() contained mad maths to figure out
icon sizes. Over time, its scope was reduced, to the point where
we are today where it mostly just redoes some quick maths to
predict the grid size based on the CSS box model.
Remove adaptToSize() from BaseAppView and child classes. It still
is an internal detail of the IconGrid class, but it's not exposed
as a "public" method anymore.
This removal is not perfect, as it doesn't move or compensate for
any of page indicators and arrows code. This will be done in follow
up commits introducing a new layout manager for that.
Another step in dismantling AppDisplay before reintroducing some
of the elements there. Instead of adding a certain amount of
padding, capped at 200px, always give the grid all available size.
The stack widget once was a ShellStack and had a prominent role
in layouting AppDisplay, but after a series of reworks it's now
effectively unused, and can be safely removed.
Florian Müllner [Wed, 3 Aug 2022 16:28:46 +0000 (18:28 +0200)]
status/network: Limit the number of items that are shown per section
Space will be less of a concern when each sections becomes its own
menu, but it's still not infinite. To address this, enable MRU
tracking and limit the list to the eight most recently used items.
Florian Müllner [Wed, 3 Aug 2022 16:12:31 +0000 (18:12 +0200)]
status/network: Add timestamp to device items
Devices do not have an associated timestamp, but as we can now
track the MRU order of their connections, it makes sense to consider
the time of the most recent succesful connection the timestamp
of the device item.
Florian Müllner [Wed, 3 Aug 2022 06:12:28 +0000 (08:12 +0200)]
status/network: Add ItemSorter option to track MRU
We always display items sorted by name, but there are cases where a
second order by recency is interesting. Add an option to ItemSorter
to keep such a list and allow accessing it with another generator
function.
Florian Müllner [Wed, 3 Aug 2022 06:12:28 +0000 (08:12 +0200)]
status/network: Add timestamp property to items
Connections have a timestamp property, which records the last time
it was succesfully activated. This is useful information to us, as
more recently used connections are likely more relevant than ones
that haven't been used for a long time (or not at all).
To make use of it in the future, expose that timestamp as a property.
Only connections support it, but we will soon provide a reasonable
value for devices as well, so add the property to the base class.
Florian Müllner [Wed, 3 Aug 2022 03:35:25 +0000 (05:35 +0200)]
status/network: Move settings item into toplevel section
Eventually each section will turn into its own menu, which should
include a single settings item.
This also removes the odd duplication of items, now that we avoid
using submenus where possible.
In general this is straight-forward, except for modems: Some
models are now supported by a dedicated wwan panel, while others
still use the generic network one.
Address this by adding items for either panel, but only show one
at a time. The new panel is used if *any* modem is supported,
only when all modems require it, the legacy panel is used.
Hopefully that shouldn't be an issue for many users, as using many
different modems with different capabilities should be fairly rare
(except for Aleksander Morgado, but I think he can handle it)
Florian Müllner [Tue, 2 Aug 2022 23:23:29 +0000 (01:23 +0200)]
status/network: Use submenus when necessary
We currently stopped using submenus altogether, but that only works
- if there is a single connection that represents
the device as a whole
- if there is just one device, so it is unambiguous
what device items belong to
To implement that behavior, add a 'single-device-mode' property that
NMDeviceSection can set on its items, and have items update their
'use-submenu' property based on that.
For wireless devices it's a straight mapping, as its items represent
wireless networks that can appear and disappear by just walking around
(multiple wifi adapters also sounds rather fringey).
Florian Müllner [Mon, 1 Aug 2022 14:59:28 +0000 (16:59 +0200)]
status/network: Track devices in NMDeviceSection
We got the indicator out of the business of tracking connections,
now it's time to do the same for devices.
Let sections track device additions and removals, and create device
items for them as it sees fit.
It also allows the sections to handle the ::activation-failed signal
by themselves, instead of passing it on from device items.
With this, the indicator is now solely responsible for global state:
Manage the top bar indicators, notify on connection failures, and run
the portal helper when NetworkManager detects a captive portal.
Florian Müllner [Mon, 1 Aug 2022 15:28:54 +0000 (17:28 +0200)]
status/network: Let device items handle their own connections
As mentioned when doing the same for VPN connections, it is currently
the indicator itself that keeps track of added and removed connections.
It then has to figure out the correct section, and iterate through all
its device items so each item can check whether the connection
corresponds to its device.
Stop that mess, and let each device item keep its connections updated
by itself. That is actually way easier, as NM.Device already exposes
available connections through a property, so we can get rid of all
the checkConnection() shenanigans.
Florian Müllner [Sat, 6 Aug 2022 00:43:29 +0000 (02:43 +0200)]
status/network: Replace wi-fi selection dialog
Now that wi-fi devices will be handled by a separate menu toggle
instead of as part of a combined system menu, there is no longer
a need of delegating network selection to a separate dialog.
To keep the menu from growing too much, the (sorted) list of
displayed networks is kept at a limit of eight. There is always
Settings for a complete list…
Florian Müllner [Tue, 2 Aug 2022 20:44:38 +0000 (22:44 +0200)]
status/network: Use SectionItem for device items
In terms of UI, this means that in the common case where we have
a single (or no) connection, the device can be represented as a
single menu item rather than a submenu.
But more importantly, all our menu items inherit from the same
GObject class now, so we can use bindings where appropriate.
Florian Müllner [Tue, 2 Aug 2022 12:04:46 +0000 (14:04 +0200)]
status/network: Add NMSectionItem subclass
The class implements a menu item that contains a section which
can be collapsed into a submenu.
It is very common for network devices to only have one associated
connection, so hiding away a single item in a submenu is fairly
inconvenient.
This class will address this, by only using a submenu when it is
actually needed.
Although the main issue it addresses is that menus (including
sections) aren't GObjects. This gives us a GObject that can
be added to a menu, and that can itself contain other menu
items.
Florian Müllner [Tue, 2 Aug 2022 11:41:13 +0000 (13:41 +0200)]
network/status: Split out NMMenuItem base class
The class only provides the GObject properties that are currently
defined by NMConnectionItem, plus a way to set the active connection
that should be used for the item's :is-active state.
Its sole purpose is to provide a shared base for both device- and
connection items, and to have that base be a GObject so we can
start linking properties via bindings rather than manual fiddling.
Florian Müllner [Sun, 7 Aug 2022 22:28:12 +0000 (00:28 +0200)]
status/network: Always use toggles in VPN section
Let's keep things simple and use the same appearance regardless
of the number of configured VPNs. Also unlike for device items,
every connection item in the VPN section is a toplevel item, so
there isn't a real need for different presentations.
Florian Müllner [Mon, 1 Aug 2022 17:08:18 +0000 (19:08 +0200)]
status/network: Decouple NMVpnSection from NMConnectionSection
The NMConnectionSection class is used - surprise - to manage a
list of related connections. And while the presentation of VPN
items is slightly different from connections associated with
devices (switches vs. ornaments), it makes perfect sense for
the VPN section to share the nitty-gritty with the base class.
But…
Right now it is perfectly fine for NMConnectionSection to be
used both as a child element in a device section, and as toplevel
item of the VPN section. Any nesting of sections is entirely
transparent to the user, and all connection sections appear as
submenu items in the toplevel menu.
That won't work for quick settings.
There's no PopoverMenuSection that allows invisible grouping, so
adding items dynamically would either need to happen at the end,
or require some tricky cross-component code to impose a particular
order.
And last but not least, quick toggles are very much unsuited for
a potentially large number of items. The whole point is to provide
quick direct access to system features, not to compete with menus
over the number of items they can hold.
That is, we need to get from the current state where each device
appears as a toplevel item, to a state where we have one quick
toggle for each device type plus one for VPN.
The decoupled VPN section still behaves largely as it did as a
subclass, with the notable difference that it no longer uses
a submenu item, so all VPN connections now appear at the toplevel.
Florian Müllner [Mon, 1 Aug 2022 16:06:08 +0000 (18:06 +0200)]
status/network: Handle VPN connections in VPN section
Right now the indicator itself tracks all devices and connections,
creates and destroys the corresponding menu items, matches them
to a section and updates the connection/device arrays that are
attached to the section.
Sounds messy?
It is slightly less effective to connect multiple handlers to the
same NMClient, but let's assume that devices and connections aren't
added/removed at 60 frames/s, and we can add some readabilty by
moving the code into different classes that only have to care about
the bits that are relevant to them.
The VPN section is a good starting point, because its handling is
already quite different from device sections.
Florian Müllner [Wed, 3 Aug 2022 14:05:20 +0000 (16:05 +0200)]
status/network: Factor out ItemSorter class
At its core, it's the sort order tracking from NMConnectionItem
with a bit of sugar on top to provide access to the ordered items
and the ability to provide a custom sort function.
Florian Müllner [Sat, 6 Aug 2022 14:15:07 +0000 (16:15 +0200)]
status/network: Sort items, not connections
You could argue that the item name is closer to what is displayed
to the user, but it doesn't really matter: Connection items will
always use the connection ID when there is more than one, which
is the only case where sorting matters.
However sorting by items will allow us to generalize the code, and
use it for items that do not represent a connection.
Florian Müllner [Tue, 2 Aug 2022 21:18:22 +0000 (23:18 +0200)]
status/network: Update appearance of connection items
When not in radio-mode - that is, in the single-connection
case - the item currently uses a plain 'Connect' label.
That is OK while the item is inside a submenu that describes
the device, but we will soon stop using a submenu when a single
item can describe the device as a whole.
Prepare for that by adding an icon that is shown when in non-radio
mode, and include the device name in the label in that case.
Florian Müllner [Tue, 2 Aug 2022 10:34:18 +0000 (12:34 +0200)]
status/network: Make NMConnectionItem a menu item
Instead of the current radioItem/labelItem shenanigans, implement
a custom menu item with a :radio-mode property to switch between
the different presentations.
Alessandro Bono [Wed, 10 Aug 2022 09:56:14 +0000 (11:56 +0200)]
cleanup: Use deepUnpack() intead of deep_unpack()
deep_unpack() is just a backwards compability alias for deepUnpack()[1].
The new name makes it more clear that this is not a C function, start to
use it.
Alessandro Bono [Wed, 10 Aug 2022 09:44:42 +0000 (11:44 +0200)]
cleanup: Minimize deep_unpack() usage
deep_unpack()[1] will unpack a variant and its children, but only up to one level.
lookup_value()[2] will directly search for a value with a linear scan.
Performing a deep_unpack() + lookup can be a more expensive operation when we are
looking for just a single value compared to just perform the lookup_value() directly
in C. Avoid the deep_unpack() usage when we perform a single check presence.
Carlos Garnacho [Tue, 9 Aug 2022 14:00:33 +0000 (16:00 +0200)]
misc: Toggle IBus OSK capability on OSK visibility
Newer versions of IBus (> 1.5.26) have the IBUS_CAP_OSK capability
which can be used to hint the active IM about an OSK driving input as
opposed to a physical keyboard. This may be used by IMs to tweak their
behavior to suit OSKs better.
Add the GNOME Shell side handling for this capability, and toggle it
on whenever the OSK is visible.
Since this is a far too new enum value and we don't want such new
IBus dependency, this change plays fast and loose with JS guarantees,
since a logical OR with an undefined value results in the other operand
unmodified it will work for older versions where the capability does not
exist and thus we want nothing extra enabled.
Alessandro Bono [Mon, 8 Aug 2022 11:33:53 +0000 (13:33 +0200)]
loginDialog: Don't call _loginScreenSessionActivated() when not required
We are calling _loginScreenSessionActivated() even in cases where this is
not required. For example, there are cases where the Active property is
already `true` and properties like `IdleHint`, `IdleSinceHint` and
`IdleSinceHintMonotonic` change. In this cases _loginScreenSessionActivated()
is called and will reset the authPrompt when not necessary.
Daniel van Vugt [Tue, 25 May 2021 09:33:01 +0000 (17:33 +0800)]
st/theme-node-drawing: Conditionally paint the center shadow rectangle
Only when part of it is actually visible.
Because the central rectangle is generally the largest part, this
eliminates most of the shadow's render time. For example, animating
`.workspace-background` by tapping Super, the shell's overall render
time is reduced about 15%.
Daniel van Vugt [Thu, 15 Jul 2021 06:18:48 +0000 (14:18 +0800)]
css: Add a special chroma key color and use it on .workspace-background
There's no visible change here since we're just moving from the
default transparent black to transparent other. But the latter can
be used as a special value to indicate to the rendering code when a
background is expected to be always occluded.
Florian Müllner [Wed, 3 Aug 2022 03:27:44 +0000 (05:27 +0200)]
status/network: Add section classes for each device type
Those will eventually become quick toggles, and as there'll be small
differences like menu headers or which settings panel to launch, it
makes sense to give each its own class.
Florian Müllner [Mon, 1 Aug 2022 14:19:43 +0000 (16:19 +0200)]
status/network: Rename DeviceCategory and base on device type
Right now DeviceCategory is a small section wrapper that shows
a summary instead of its content if it contains too many items.
It will eventually eventually turn into the base class for
network device quick toggles. Who would have thought that
when it was added for the "there's a computer with 32 ethernet
cards" fringe case?!
For now, give it a more appropriate name and use device types
instead of our made-up categories, now that the two map neatly.
Florian Müllner [Mon, 1 Aug 2022 13:13:06 +0000 (15:13 +0200)]
status/network: Give bluetooth its own category
In the quick settings future, each device type will use a separate
toggle. We still have a long way to go, but start with giving
bluetooth its own section/category. Baby steps …
Florian Müllner [Tue, 2 Aug 2022 09:33:37 +0000 (11:33 +0200)]
status/network: Remove status from VPN item
It's odd to swap out a switch with a status label, and the
information isn't that helpful to begin with: It's either
transient (connecting, deactivating, ...), or too little to
be meaningful (unknown, failed, ...).
We're also perfectly happy to not show it in "label mode"
(i.e. when there's just one VPN).
Florian Müllner [Thu, 4 Aug 2022 23:37:56 +0000 (01:37 +0200)]
status/network: Simplify device item labels
Stop providing detailed state descriptions, instead use a name
that best represents the device at the moment (like a wifi SSID,
the carrier name, or the device name as determined by network manager).
Different access points can belong to the same wireless network. As
NetworkManager doesn't handle this for us, we need to track networks
ourselves, and we currently do this using ad-hoc object literals and
monkey-patching.
Clean this up by factoring out a proper WirelessNetwork class, and
associate them to items with a map.
status/network: Use NM utility function for classifying security
Interpreting the different flags is better left to the domain
experts at NetworkManager. It is also much more likely that
NM's own functions will handle newly added flags than our own
code.
status/network: Use connectObject() to connect client signals
We would want the signals to be disconnected if we ever happened to
destroy the indicator. Even if we don't, connectObject() is simply
nicer when connecting half a dozen handlers at once.
There is only one case where we show a notification: When activating
a connection failed.
There is therefore no reason for a generic wrapper around the
notification API. Likewise, tracking the source is a bit pointless,
given that the notification is transient. In fact, as we destroy
an existing notification *before* checking for the source, any
previous source will be gone by that point.
Florian Müllner [Fri, 5 Aug 2022 21:21:21 +0000 (23:21 +0200)]
status/network: Fix error notification for wireguard
The function is a handler for the `notify::state` handler, so
the state and reason parameters used in the checks are always
undefined.
In addition, `DEACTIVATED` is not (just) a failure state. We
clearly don't want to complain about a failed connection when
the change happened on request of the user.
Florian Müllner [Fri, 5 Aug 2022 11:21:26 +0000 (13:21 +0200)]
status/network: Emit 'icon-changed' on primary connection changes
When deciding on whether to show the 'no-route' icon, we check
for the client's connectivity *and* whether the devices's active
connection is used as primary connection.
This is currently masked by the indicator updating the icon on
connection changes anyway, but items should still notify the
change themselves.
Florian Müllner [Mon, 1 Aug 2022 14:55:12 +0000 (16:55 +0200)]
status/network: Catch errors when fetching client
Otherwise any unrelated errors in that function are hidden,
because exceptions in async functions are turned into promise
rejections (and JS cannot know that we won't handle it at a later
point).
Alessandro Bono [Fri, 5 Aug 2022 10:56:04 +0000 (12:56 +0200)]
authPrompt: Don't propagate serviceName to setMessage
There isn't always a serviceName when we set a message. Furthermore we
are passing the serviceName only to decide if we want to wiggle or not.
Pass the wiggle parameters instead. If they are missing, we don't want
to wiggle.
This fixes the following error:
JS ERROR: Exception in callback for signal: login-format-changed: Error: Wrong type number; string expected
setMessage@resource:///org/gnome/shell/gdm/authPrompt.js:542:13
_showRealmLoginHint@resource:///org/gnome/shell/gdm/loginDialog.js:931:26
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:114:47
_updateLoginFormat@resource:///org/gnome/shell/gdm/realmd.js:85:18
_reloadRealm@resource:///org/gnome/shell/gdm/realmd.js:57:14
_onRealmLoaded@resource:///org/gnome/shell/gdm/realmd.js:64:14
_makeProxyWrapper/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:245:34
Now that the old system menu has been ported over, we can move
the power toggle to its intended place. The main difference to
the stand-alone toggle is that the button now uses its natural
size rather than the fixed size of regular quick items.
This port is a bit messier than the previous ones, because the
existing menu section translates less directly to the new UI,
which uses a row of individual toggles for settings, lock and
shutdown.
In order to not complicate the grid layout further by supporting
rows with a different number of columns than the overall grid and
children at their natural size, create a custom, non-reactive
SystemItem item that spans an entire row, and contains the individual
toggles.
This works quite well, even with the shutdown item that uses a menu
for the various actions.
projects / gnome-shell.git / log